The present invention relates to tools for software development. In particular, the present invention relates to a tool for developing embedded systems.
Microprocessors are showing up in almost every imaginable piece of hardware, from computer monitors to network routers to automobiles to intelligent household appliances. This proliferation means that more software must be developed by more programmers. This software is closely tied to the system hardware.
Because of this, software development is usually delayed until the system hardware is available. Software developers would like to write, test, and debug software in parallel with hardware development.
Several methods are currently available to allow software to be run and debugged before the hardware system is available. The programmer can use a demo board, a hardware emulator, a re-targeting compiler, an instruction level simulator, or software models.
A demo board is typically provided by a processor manufacturer for the purpose of debugging software before hardware is available. A demo board includes the same processor as the target system hardware. A demo board also includes memory and a number of standard hardware interfaces. Software can be loaded into memory and run by the processor on the demo board. A demo board can be connected to other systems through its standard interfaces.
A major drawback of a demo board is that it can only support specific, standard interfaces. If interfaces on the hardware system being developed are not identical to those on the demo board, the system interfaces cannot be tested. If the hardware on the demo board is not identical to the hardware in the system begin developed, the system software will need to be modified in order to use it on the demo board. As larger numbers of modifications are required for the software to run on the demo board, a developer will spend more time later debugging the real system software on the real target system hardware, making the demo board a less effective tool.
A hardware emulator is a special purpose computer that simulates hardware. Companies such as Mentor Graphics, Quickturn Design Systems, and Axis Systems sell hardware emulators. To use a hardware emulator, a developer first creates a hardware design using a hardware description language such as Verilog or VHDL. Typically, the design describes system hardware at a register transfer level (RTL) or at a gate level, though it is also possible to describe the system hardware at a behavioral level. The description is compiled and downloaded into the hardware emulator. The hardware emulator then executes the functionality of the hardware. The hardware emulator can emulate a chip, a board, or an entire system. The hardware emulator has input and output connectors, allowing it to emulate simple interfaces to other hardware and other systems. The hardware emulator can also plug into a target board or target system and control the hardware interfaces of the target board or system. Software can be loaded into memory on the target board or system and the hardware emulator will run the software just as the real system hardware will.
There are several drawbacks to using a hardware emulator for software development. First, a hardware emulator runs one or two orders of magnitude slower than the real system hardware. Real-time embedded systems have timing requirements and responses to specific events must occur within a set time limit. A hardware emulator cannot test this important timing function of the software. Also, external hardware often includes timeouts that cause the hardware to give up and assume that there is a problem with the system if a device does not respond to an event within a certain time. In many cases, a hardware emulator cannot respond in time and therefore cannot be connected to an external system. Because of the slow speed of hardware emulators, only a limited number of instruction cycles can be executed. Also, a complete hardware design must be loaded into the emulator, so a hardware emulator can only be used after the hardware design is nearly complete. Thus, software debugging must still wait until an advanced stage of the hardware design. Hardware emulators also tend to be very expensive.
A re-targeting compiler is software that runs on a host computer with a particular processor. A re-targeting compiler takes high-level code written in a language like C, C++, or Pascal and compiles it into low-level machine code for a different processor on the target system hardware. For example, with a re-targeting compiler, high-level code written for an ARM processor can be compiled for a Pentium processor, allowing the code to run on a conventional personal computer (PC).
A real-time operating system (RTOS) is defined as an operating system designed specifically for use in real-time systems. A real-time system is defined as any computer system, embedded or otherwise, that has timeliness requirements. The following question can be used to distinguish real-time systems from the other types of systems: “Is a late answer as bad, or even worse, than a wrong answer?” In other words, what happens if the computation doesn't finish in time? If nothing bad happens, it is not a real-time system. If someone dies or the mission fails, it is generally considered “hard” real-time, which is meant to imply that the system has hard deadlines. Everything in between is a “soft” real-time system.
The main disadvantage of using a re-targeting compiler to debug software for a real-time system is that it cannot be used for testing hardware interfaces. The compiled code must be run and debugged on a host hardware system that is different from that of the target system hardware. Even if the interfaces were similar on both systems, the driver software required to access the interfaces differs substantially on each system. Controlling interface hardware requires long sequences of code. A re-targeting compiler works at too low a level to convert a hardware device driver used by one system to one that will work on another system.
An instruction set simulator is software that runs on a computer and interprets low-level instructions for another computer, allowing software written for one system to be executed on a different system that is easily available. For example, with an instruction level simulator, software can be written for an embedded system that uses an ARM processor. There are currently no general-purpose computers based on ARM processors. An instruction set simulator running on a PC that uses an Intel Pentium processor reads each low-level ARM instruction and executes one or more low-level Pentium instructions to perform the same action as the ARM processor would.
An instruction set simulator is useful for debugging code. However, like a re-targeting compiler, it is not useful for testing hardware interfaces. The hardware of the computer on which an instruction set simulator is running often is substantially different from that of the system hardware. Even if the interfaces are similar, the driver software required to access the interfaces on the computer running the instruction set simulator will be different from the driver software required to access the interfaces on the actual target system. Driver software requires long sequences of code to control interface hardware. An instruction set simulator works at too low a level to convert a hardware device driver used by one system to a hardware device driver that will work on another system.
An instruction set simulator is still much slower than the real target system because each instruction must be read and emulated in software. As stated earlier, real-time embedded systems have timing requirements, and responses to specific events must occur within a set time limit. A hardware emulator cannot test this important timing function of the software. Also, external hardware often has timeouts that cause the hardware to give up and assume. that there is a problem with the system if a device does not respond to an event within a certain time. In many cases, an instruction set simulator cannot respond in time and therefore cannot communicate with an external system.
Software models of hardware can also be used to debug software. These models run in a simulator on a general-purpose computer. Software models act as virtual hardware with virtual interfaces. Software can be loaded into the memory of these models and the model of the processor will run the code in the model of the memory. The processor model can access models of interface devices, which can communicate with models of real world systems. Software models can model very large systems. Software can be run on these models and the effects of the software on very large systems can be observed.
One disadvantage of software models is that models are much slower than real hardware. Critical timing cannot be examined using software models. Also, models must be written for each piece of hardware that needs to be tested, including the processor, memory, and all hardware interfaces. Models must be written to simulate real-world data coming into the software models. Finally, the accuracy of the models is open to question. It is very difficult to create a high-level software model that is even close to 100% accurate.